-
Notifications
You must be signed in to change notification settings - Fork 24
EZEE-1780: Plugin support #19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
src/Resources/config/view_cache.yml
Outdated
| ezplatform.view_cache.response_tagger.restlocationbc: | ||
| class: EzSystems\PlatformHttpCacheBundle\ResponseTagger\Value\RestLocationBCTagger | ||
| tags: | ||
| - {name: ezplatform.cache_response_tagger} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bdunogier :
I really don't get the reasoning behind splitting the response taggers in delegators and values. It just creates overhead? Also, given that we keep this split, why does also the value tagges have the ezplatform.cache_response_tagger tag? It means they are invoked both by the dispatcher directly, and by their deligator
| $view = $event->getRequest()->attributes->get('view'); | ||
| if (!$view instanceof CachableView || !$view->isCacheEnabled()) { | ||
| return; | ||
| if ($event->getRequest()->attributes->has('is_rest_request') && $event->getRequest()->attributes->get('is_rest_request') === true) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe this subscriber needs a new name, but this subscriber to me is for ContentView.
Not all rest requests are supposed to be cacheable afaik, so if (we make it) expose RestValue or something on Response (is it maybe still on the getControllerResult?), then we can have a dedicated subscriber for rest responses.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see #25 I would think this part is not needed anymore if we handle X-Location-Id issue in separate listener
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 on @andrerom comment
| { | ||
| // Rest API sets the X-Location-Id header. This needs to be changed according to http cache in use | ||
| if ($value === null && $response->headers->has('X-Location-Id')) { | ||
| $this->restLocationBCTagger->tag($configurator, $response, ['X-Location-Id' => $response->headers->get('X-Location-Id')]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kind of duplicates #21
And it seems a bit strange to use several layers of response taggers to map X-Location-id to xkey and remove it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and now it is also useless because of #25 I think
| /** | ||
| * Purge client based on FOSHttpCacheBundle. | ||
| * | ||
| * Only support BAN requests on purpose, to be able to invalidate cache for a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BAN not updated right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, that was an old comment... Removed it
| // eZ\Publish\Core\MVC\Symfony\Cache\Http\FOSPurgeClient | ||
| // Or else, that deprecated class is still used by cache:clear | ||
| if ($purgeType !== 'local') { | ||
| $container->setAlias('ezpublish.http_cache.purge_client', $purgeServiceId); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should use ezplatform.http_cache.purge_client I think because this bundle is overriding it
See other bug
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
15 was not necessarily the final say on it, it was to solve a bug where kernel purge system will be called on cache:clear, when if we need such logic should have the proper config for it here.
But we don't clear Stash / Symfony cache either on cache:clear by default (unless file system cache is used), but it should be possible somehow to do it when content or schema for some reason changes on deployment. If so, purge for symfony cache, and expire (soft purge) for http cache.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But this line can indeed be removed, ca:cl is not supposed to call kernel purge client anymore with this bundle enabled. Actually almost all http cache code in kernel is deprecated in favor of this bundle.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in any case are we sure we don't want to use ezplatform.http_cache.purge_client and not ezpublish.http_cache.purge_client one is meant to replace the other right ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think I understood your last comment, but I have removed the line in question as it does not do anything after #15 was merged
| { | ||
| public function process(ContainerBuilder $container) | ||
| { | ||
| $purgeType = $container->getParameter('purge_type'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should not use the parameter here... that could be renamed. we should use the ezpublish.http_cache.purge_type settings
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm.. Not sure that is possible in a compiler pass. You know how?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not by default, I think, no way :( But for sure we should do that on purge_type.
You will have to set the value as a parameter here:
https://github.com/ezsystems/ezpublish-kernel/blob/master/eZ/Bundle/EzPublishCoreBundle/DependencyInjection/EzPublishCoreExtension.php#L392
$container->setParameter("ezpublish.http_cache.purge_type", $config['http_cache']['purge_type']);And then refer to it
$purgeType = $container->getParameter('ezpublish.http_cache.purge_type');Then comes the SiteAccess Awareness, but I think that is global then a parameter would be fine.
@andrerom @bdunogier another idea?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, fixed as suggested
f71ee94 to
7030246
Compare
7030246 to
8e4595d
Compare
This reverts commit 6b1dafa.
a3e83d7 to
5702f5f
Compare
| * Triggers the cache purge $locationIds. | ||
| * Triggers the cache purge of $tags. | ||
| * | ||
| * It's up to the implementor to decide whether to purge $locationIds right away or to delegate to a separate process. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
$locationIds
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So you insist on calling it $locationIds ?
It is not consistent with https://github.com/ezsystems/ezplatform-http-cache/pull/19/files#diff-cdb40d122691729c63752db68cddf3f9R31 and other places
And besides, there are not only location ids, also path-XX, content-XX and content-type-XX etc.....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, you misunderstand me. I was referring to text here mentioning $locationIds when it should be aligned with the other changes you make to refer to tags instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah... missed that one.. will fix
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1, but I guess this depends on kernel changes
so:
- I'll ping you on that separately
- Requirement for kernel should then be bumped here in this PR to:
"ezsystems/ezpublish-kernel": "~6.7.7@dev || ^6.12.1@dev || ^7.0@dev"
DominikaK
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few language nitpicks in the doc.
docs/drivers.md
Outdated
| - TagHandler | ||
| - FOS TagHandler | ||
|
|
||
| If you write a new PurgeClient driver, you **must** also create a corresponding TagHandler and vise |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...TagHandler and vice
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
docs/drivers.md
Outdated
|
|
||
| The PurgeClient is responsible for sending purge requests to the http cache when content is about to be invalidated. | ||
| The PurgeClient must implement EzSystems\PlatformHttpCacheBundle\PurgeClient\PurgeClientInterface and can be registered | ||
| with the following code in service.yml: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't it serviceS.yml?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, it is. good catch....
docs/drivers.md
Outdated
|
|
||
| ## FOS TagHandler | ||
|
|
||
| The FOS Http cache bundle also have a TagHandler which is not used by eZ Platform except for one thing, the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...also has a TagHandler...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
docs/drivers.md
Outdated
| ## FOS TagHandler | ||
|
|
||
| The FOS Http cache bundle also have a TagHandler which is not used by eZ Platform except for one thing, the | ||
| `fos:httpcache:invalidate:tag` command. With this command you may explicit invalidate cache by tag. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...you may explicitly invalidate cache...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
docs/drivers.md
Outdated
|
|
||
| Normally, you would not need to implement your own FOS TagHandler as the ezplatform-http-cache bundle ships with a | ||
| default one which uses the PurgeClient to invalidate the given tags. | ||
| If you anyway need to write your own FOS TagHandler, you may register it with the following code in service.yml: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you need to write your own FOS TagHandler anyway...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
03f66f2 to
aeb62eb
Compare
|
|
||
| public function getAlias() | ||
| { | ||
| return 'ez_platform_cache'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ez_platform_http_cache, method can afaik be avoided by renaming this class to EzPlatformHttpCacheExtension which getContainerExtension() will then need to be adapted for.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that will be better. If I rename class, then I think the most clean way should be to also override Bundle::getContainerExtensionClass() ( and not write logic concerning class name in getContainerExtension() ).
So IMO it is either to create a getAlias() or a getContainerExtensionClass() method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Replaced getAlias() with getContainerExtensionClass()
aeb62eb to
5e4295f
Compare
5e4295f to
fb34440
Compare
composer.json
Outdated
| "minimum-stability": "stable", | ||
| "require": { | ||
| "ezsystems/ezpublish-kernel": "^6.7@dev || ^7.0@dev", | ||
| "ezsystems/ezpublish-kernel": "~6.7.7 || ^6.12.1 || ^7.0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you'll need to keep dev for tests to continue to work
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed in 358a682
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed again in b8a2348
please pull in changes before rebasing ;)
docs/drivers.md
Outdated
| services: | ||
| ezplatform.http_cache_myhttpcachebundle.purge_client.myhttpcache: | ||
| class: EzSystems\PlatformMyHttpCacheBundle\PurgeClient\MyHttpCachePurgeClient | ||
| arguments: ["@ezplatform.http_cache.cache_manager"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nitpick: Let's advocate in doc single quotes as well here. Sorry to be persistent and boring, just trying to clean the mess I made some time ago ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no reason to apologize. I guess I should use single quotes in the actuall services.yml to then... Will fix
| if ($this->extension) { | ||
| return $this->extension; | ||
| } | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why can't we just return new EzPlatformHttpCacheExtension()? See Symfony doc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah.... man.... This we talked about yesterday
Ok, I'll change it again
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I think I missed the point of that discussion and didn't see this code yesterday. Doing too many things at the same time ;)
| use Symfony\Component\DependencyInjection\ContainerBuilder; | ||
| use Symfony\Component\DependencyInjection\Reference; | ||
|
|
||
| class DriverPass implements CompilerPassInterface |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nitpick: Please add brief description on what this Compiler Pass does.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
358a682 to
206d19d
Compare
…tpCacheExtension class
d7e00cf to
14344d1
Compare
This PR makes it possible to extend http cache in 3rd party bundles
Depends on:
EZP-28243: Purge type using service id does not work ezpublish-kernel#2136(merged)